Certain video coding standards were conceived in the context of video conferencing and digital TV environments, where the spatial resolution and orientation of a captured or reconstructed video signal can be the same on the capture/encoder and decoder/display site. For example, a TV signal can be captured in landscape format at 4:3 or 16:9 aspect ratio, and is rendered also in landscape format (though the aspect ratio may be adjusted in the receiving TV based on user preferences). Coincidentally, certain video compression standards, including ITU-T Rec. H.261, H.262, H.263, H.264, (all available from the International Telecommunication Union (“ITU”), Place de Nations, CH-1211 Geneva 20, Switzerland or www.itu.int), and MPEG-1 visual (formally known as ISO/IEC 11172-2), and MPEG-4 visual (formally known as ISO/TEC 14496-2), available from the International Organization for Standardization (“ISO”) 1, ch. de la Voie-Creuse, Case postale 56, CH-1211 Geneva 20, Switzerland, or www.iso.org, (all incorporated herein by reference in their entirety), do not include information related to the spatial orientation of the captured video signal.
The use of screens connected to computer-based decoders/rendering devices, be they located on Personal Computers (PCs), set-top-boxes, mobile devices such as cell phones and tablet computers, or any other similar device, allows to render a video image also in orientations that are not the native orientation of the device, for example by putting them in a “window” on the screen. Some of the aforementioned devices allow, inherently due to their form factor as they are handheld, or by technical means (swivel monitors), to be viewed in more than one orientation. Operating systems and GUIs may not care about the “native” orientation of a reconstructed video signal.
What was mentioned above applies, in concept, equally to the capture side. While, today, TV and video conferencing visual signals can be (and mostly are) captured in landscape mode, there is no technical reason not to rotate the camera around its capturing axis, and thereby capture at a different orientation. Doing so can require the rendering device to rotate the reconstructed picture as well, so to enable a natural viewing experience.
Without having a mechanism that allows, in the video bitstream, an indication of the orientation of a to-be-rendered video bitstream (after reconstruction), a rendering device cannot make an informed decision for the rendering orientation, which can lead to a bad user experience.
Further, it is an option for artistic expression of a movie producer to rotate a camera during production. For or a faithful viewing experience, the rotation needs to be synchronized with the video content, as it can change during a sequence. This makes file format based orientation information, such as the one known from extensions to the JFIF standard (Draft ISO/IEC 10918-5, available from the International Organization for Standardization (“ISO”) 1, ch. de la Voie-Creuse, Case postale 56, CH-1211 Geneva 20, Switzerland, or www.iso.org and incorporated herein by reference) incapable to provide the desired functionality. For a meaningful synchronization of camera orientation with video content, orientation information needs to be available in the video bitstream.
Therefore, it can be desirable, in a video bitstream, to have a mechanism that allows to signal the orientation of a to-be-reconstructed bitstream.